-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Add Github Actions #41
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great effort!
Overall, a bit frustrating that we need to introduce a separate tagging convention just for a single service type (nodejs). Are there any alternatives that do not affect the tagging? @jrwbabylonlab
This also breaks the automated devnet deployment for the simple-staking service on babylon-service-deployment:
Not i'm aware of. FE deployment is always quite different to others as it does not dynamically accept envs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, although this again introduces coupling between a service repository and an internal deployment. No problem with merging this now, but we should remove the tight coupling from here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As we discussed offline, we can merge this for now.
The next iteration involves templatizing the extra publish logic into the reusable publish workflow.
@maiquanghiep it's best to squash merge. otherwise we end up with too many random commits |
@jrwbabylonlab Sorry my bad, selected squash but forgot to do the same after reloading the page |
No description provided.